Combinatorial Approach to Prevent SQL Injection Attack

 

Neha Tiwari1, Praful Daharwal2, Samrat Kavishwar2

1Assistant Professor, Dept. of Information Technology, Nagpur Institute of Technology, Nagpur

2Assistant Professor, Dept. of Mechanical Engineering, Nagpur Institute of Technology, Nagpur

*Corresponding Author:

 

ABSTRACT:

As more businesses and organizations provide online services, the number of web sites  or applications which are linked to a database has increased greatly. Often the data held in such databases is confidential or private – and possibly of great interest to a hacker, disgruntled employee, or criminal group. While the database and the server holding it may have been secured, the design of the web interface is often overlooked and could allow unauthorized users access to the database. SQL injection, the use of database commands in the SQL language where user input is expected, remains a top threat. It was the 3rd listed error in the January 2009 “CWE/SANS Top 25 Most Dangerous Programming Errors”[a] and has been the mechanism for a number of prevalent attacks. For example, through most of 2008 there were ongoing, indiscriminate and widespread attacks on vulnerable web sites, which added a link to a malicious file (usually JavaScript) that most web site visitors would unintentionally run on loading the page. This then caused the visitor’s computer to be infected with malware. Even well-known and widely trusted web sites were affected by this problem. This document will illustrate some of the main techniques used in SQL injection, then describe methods that can reduce the effectiveness of such attacks. In addition to usual standard IT best practice, such as logging and regular and prompt patching, the majority of SQL injection vulnerabilities can be moderated through careful and robust programming. It is hoped that the information provided here will highlight the seriousness of leaving this type of flaw unaddressed and promote the improved design of database-linked Internet resources.

 

KEY WORDS:

 


 

INTRODUCTION:

Structured Query Language (SQL) is used to interrogate and manage relational databases such as Microsoft SQL Server, MySQL, Oracle, Postgress SQL and Sybase. While there is an ANSI/ISO standard for SQL defining elements such as keywords and grammar, most of the major implementations do not employ the full SQL standard and add implementation-specific procedural extensions. For this reason much SQL code is written for a certain target platform and is unlikely to transfer easily to another.

 

SQL injection occurs when an SQL instruction is entered in a field of an application or web page that a user can change in an attempt for it to be passed to and executed by the back-end database.

 

There are a number of forms of SQL injection, which can be broadly separated into input validation circumvention and blind SQL injection. While some attacks are directed at a weakness in the database software, the majority of attacks seen use a flaw in the interface to the database to (without permission) access, add, or modify data, or to execute a command on the server itself. Clearly there can be serious consequences when a malicious SQL injection attack succeeds, affecting the confidentiality, integrity and availability of the data and services it supports.

 

Problem  Definition:

As more businesses and organizations provide online services, the number of web sites  or applications which are linked to a database has increased greatly. Often the data held in such databases is confidential or private – and possibly of great interest to a hacker, disgruntled employee, or criminal group. While the database and the server holding it may have been secured, the design of the web interface is often overlooked and could allow unauthorized users access to the database. SQL injection, the use of database commands in the SQL language where user input is expected, remains a top threat. It was the 3rd listed error in the January 2009 “CWE/SANS Top 25 Most Dangerous Programming Errors”[a] and has been the mechanism for a number of prevalent attacks. For example, through most of 2008 there were ongoing, indiscriminate and widespread attacks on vulnerable web sites, which added a link to a malicious file (usually JavaScript) that most web site visitors would unintentionally run on loading the page. This then caused the visitor’s computer to be infected with malware. Even well-known and widely trusted web sites were affected by this problem. This document will illustrate some of the main techniques used in SQL injection, then describe methods that can reduce the effectiveness of such attacks. In addition to usual standard IT best practice, such as logging and regular and prompt patching, the majority of SQL injection vulnerabilities can be moderated through careful and robust programming.

 

Existing System:

SQL injection occurs when an SQL instruction is entered in a field of an application or web page that a user can change in an attempt for it to be passed to and executed by the back-end database. There are a number of forms of SQL injection, which can be broadly separated into input validation circumvention and blind SQL injection. While some attacks are directed at a weakness in the database software, the majority of attacks seen use a flaw in the interface to the database to (without permission) access, add, or modify data, or to execute a command on the server itself. Clearly there can be serious consequences when a malicious SQL injection attack succeeds, affecting the confidentiality, integrity and availability of the data and services it supports. The purpose of this document is to demonstrate why it is necessary to code web pages and applications securely, giving examples of SQL injection attacks and to summaries some ways that these systems can be secured.

 

Proposed System:

SQL injection is one of the main issues in database security. It is a technique that may corrupt the information in the database i.e. deletes or changes the full database or records or tables. To exploit the database system, some vulnerable web applications  are used by the attackers. These attacks not only make the attacker to breach the security and steal the entire content of the database but also, to make arbitrary changes to both the database schema and the contents. The following section describes the attacks with an example.

Generally the Authenticated users have username and password such as,

 

Username: rahul

Password: 123

 

The SQL Query format will be as follows,

Select * from table where username='rahul' and pwd='123';

 

The above query then retrieves the needed records from the database where username and pwd is available in the database or it shows some error messages to the browsers. The unauthorized users or the attackers inject the following SQL Injection in this field:

 

Username: r hul

Password: 123

 

Then the dynamic SQL query constructed from the above information is,

Select * from table where username=' r hul ' and pwd=123;

 

In this SQL statement, the actual username is ‘rahul’ which is modified as ' r hul’ by the attackers while generating the Query. This includes the image of ‘a’ in place of the character ‘a’. The attacker will now have the capability of attacking the database by writing the injection code at the inside location of the image (just as-image processing).

 

Scope and Objective:

A new approach for protecting Web applications-An Image level Tainting, involves comparing the SQL statements that includes the images viewed as characters in the user input with the Meta strings library, to prevent them if found any and protecting the web applications against SQL injection is discussed in this paper. This project  includes the strange idea of combining the Indication based method and the Inspection Method. The main problem that occurs with web application security is the SQL Injection, which gives the attackers unauthorized access to the database that contains the Web applications. This leads to the cause of calamities in the Web applications and this is very serious. On the other hand from the Inspection based method point of view, it analyzes the transaction to find out the malicious access. In Indication based method it uses an approach called Beschermen algorithm, not only to prevent the SQL Injection attacks, but also reduces the time and space complexity.

 

LITERATURE SURVEY:

Boyd, Keromytis-2004 proposed SQLr and which uses instruction set randomization of SQL statement to check SQL injection attack. It uses a proxy to a append key to SQL keyword. A de-randomizing proxy then converts the randomized query to proper SQL queries for the database. The key is not known to the attacker, so the code injected by attacker is treated as undefined keywords and expressions which cause runtime exceptions and the query is not sent to database. The disadvantage of this system is its complex configuration and the security of the key. If the key is exposed, attacker can formulate queries for successful attack.

 

Russell A. McClure and Ingolf H. Kruger-2005 proposed SQL DOM (SQL Domain Object Model): a set of classes that are strongly-typed to a database schema. Instead of string manipulation, these classes are used to generate SQL statements. We show how to extract the SQL DOM automatically from an existing database schema, demonstrate its applicability to solve the problems, and evaluate its performance.

 

Ke Wei et al.-2006 proposed a novel technique to defend against the attacks targeted at stored procedures. This technique combines static application code analysis with runtime validation to eliminate the occurrence of such attacks. In the static part, we design a stored procedure parser, and for any SQL statement which depends on user inputs, we use this parser to instrument the necessary statements in order to compare the original SQL statement structure to that including user inputs.

 

Recently, researchers have been exploring the use of static analysis in conjunction with runtime validation to detect instances of SQLIAs. In Buehrer and Weide have proposed the use of parse trees to detect malicious user input, which requires a developer to manually modify new and existing code. As mentioned above, it is hard to predict the exact structure of the intended SQL statement. Also there is an additional runtime analysis overhead in terms of execution time which cannot be avoided due to the sequential nature of the analysis techniques. The use of stored procedures alone does not protect one against SQLIAs as is commonly assumed by most developers, but appropriate use of parameters along with stored procedures is necessary to achieve a minimal defense against such attacks .Various SQLIA detection techniques for the application layer have been proposed in literature, but none of them pay enough attention to SQLIA in stored procedures.

 

ARCHITECHTURE DESIGN:

Architecture of the proposed technique consists of three components. These are User Login Interface, SQL Injection Protector for Authentication (SQLIPA) and User_account table as shown in figure 7.

 


 

Here, User Login Interface is just the user entry form for user name and password. User_account is the table which stores user accounts data. Main component of the architecture is SQL Injection Protector for Authentication. It is the component which generates the hash values of user name and password for the first time during the creation of user account and every time when an existing user wants to login into database. Subcomponents of the SQL Injection Protector for Authentication are “User Name Hash Value” and “Password Hash value”. User Name Hash Value generates hash of user name and Password Hash value generates hash value for password.

 

Contraints:

A prototype named SQL Injection Protector for Authentication (SQLIPA) has been developed for evaluating the proposed technique. Two store procedures with name Create_user_account and User_authentication have been used. Create_user_account store procedure is

 

used when a new user account is created for the first time. Reciting module includes the Meta strings library which comprises the predefined keywords and is updated with new type of information in terms of coordinates of the images, their pixels information, color resolution and the details on type of images. If both comparative module and inspection module has satisfied, it provides the complete transaction.

 

Assumptions and Dependencies:

Authorization Diversions (SQL Manipulation)

This attack allows the attacker access the total information in the database [15]. The example of this attack is discussed in the above section.

 

Exploiting Insert:

The Web Sites like Banking, when registration, it allows the user to feed inputs and store it. INSERT statement allows the user input to store in the back end. The misuse of INSERT statements by the attacker results in many rows in the database with corrupt data.

 

Exploiting SELECT:

SQL injection is not only a straight forward attack but also it has some background tricky attack is present. Most of the time attackers would see some error message and will have to reverse engineer their queries..Direct Vs Informative (SQL manipulation) – Both Direct and informative are the types of SQL Injection attacks in SQL manipulation. In direct attack, the input data become part of the SQL statement formed by the application. Attacker has to add image in place of a character in a way that image is also visible as character which manipulates the SQL statement. The error message has been returned if the injection was successful.

 

Exploiting System Stored Procedures (Function Call):

Database uses stored procedures to perform database Administrative operations. Attacker uses stored procedures to corrupt the database system and it’s a most harmful attacks.

SELECT usrid, details, username from user where username like ‘r hul’; to execmaster.dbo.xp_cmdshell "dir.

 

Reciting Module:

Reciting module includes the Meta strings library which comprises the predefined keywords and is updated with new type of information in terms of coordinates of the images, their pixels information, color resolution and the details on type of images

 

Comparative Module:

In Comparative module, it gets an input from the web application and it compares the statement with the Meta strings library included in the Reciting Module, if founds any error message it attempts to block the query.

 


 

E-R Diagram:

 

 


Every time a client request comes in, the runtime finite state automata of the different SQL queries in the SQL-graph are validated. A Verification Table (VT) is then computed for the different SQL queries indicating whether it can be allowed to pass through or whether it should be dropped before being sent to the database. Now verifying the finite state automata for all the queries in the SQL-graph can be computationally intensive and can be expensive in terms of the runtime processing time for the stored procedure. The concept of the directed dependency in the SQL-graph is used to reduce the total runtime overhead.

 


 

UML Diagram

 

Class Diagram

 

 


The on waiting list association is unidirectional because there isn’t yet a need for collaboration in both directions.   The enrolled in association between the Student and Enrollment classes is also uni-directional for similar reasons. For this association it appears student objects know what enrollment records they are involved with, recording the seminars they have taken in the past, as well as the seminars in which they are currently involved. The instructs association between the Professor class and the Seminar class is bidirectional because professor objects know what seminars they instruct and seminar objects know who instruct them.

When I’m conceptual modeling my style is to name attributes and methods using the formats Attribute Name and Method Name, respectively.  Following a consistent and sensible naming convention helps to make your diagrams readable, an important benefit of AM’s Apply Modeling Standards practice. Also notice in Figure 2 how I haven’t modeled the visibility of the attributes and methods to any great extent. Visibility is an important issue during design but, for now, it can be ignored.

 


Use Case Diagram

 

Sequence Diagram

 

Activity Diagram

 

 


MODULE DESIGN:

Reciting module includes the Meta strings library which comprises the predefined keywords and is updated with new type of information in terms of coordinates of the images, their pixels information, color resolution and the details on type of images (extension files like .jpg etc). If both comparative module and inspection module has satisfied, it provides the complete transaction. The following section outlines each module's work in detail.


 

 


Reciting Module:

Reciting module includes the Meta strings library which comprises the predefined keywords and is updated with new type of information in terms of coordinates of the images, their pixels information, color resolution and the details on type of images (extension files like .jpg etc).

 

Comparative Module:

In Comparitive module, it gets an input from the web application and it compares the statement with the Meta strings library included in the Reciting Module, if founds any error message it attempts to block the query. The time complexity of this algorithm is O(nm) and space complexity is O(min(nm)).

 

Beschermen Algorithm:

Beschermen algorithm is generally applicable algorithm for finding an optimal sequence alignment. Let, The Statement generated from the Web application is =Q The Character of the Statement is =C, The Meta String Library = M .The Pixel Size of the statement= X The Original Statement included in the Meta String library= S.

 

Hence, The Pixel size of the generated Statement = Q(X),

The Pixel size of the original String in Meta Strings Library = M(S(X)).

SQL Injection code

Select * from table where username=' r hul ' and pwd=123;

 

DATABASE DESIGN:

This is a very important issue to consider when you're using form/url variables in databases.. I get the feeling that there are several people that aren't aware of this when they develop their apps. For example, if you define something expecting an integer, and a user manually puts in

 

99999999999999999999999999999999999999999999999999999999999999999 9999999999999999999999999999999999999999999999999999999999 it can cause unexpected results.

Strings - if it’s a value from a list box or pull down menu, error check for those values in the script... if anything else, take necessary action. If it's a string the user has to put in, check if the first chars are: ' or " or ; - (If the user is expected to put in a their name, a number, a name, there should be no reason why they would be putting fields/chars that are part of SQL statements. Also make sure you always replace all <>"& with their html entities. When accepting variables from a form/url make sure you have a function that always replaces single apostrophes with double apostrophes.

select * from customers


where customerid = 'ALFKI'

"ALFKI" in this case is dynamically inserted through whatever script language into the SQL statement. There's nothing wrong with this statement. Now, what if the user inserts the following?

 

ALFKI';select * from customers - -He enters the above as you see it. With the apostrophes, semicolon, asterisk, and two dashes at the end. This statement will append another SQL statement to the previous. So now you will get a list of customers where customerid = ALFKI and another list of everyone under customers.


The first apostrophe you see in the SQL statement in figure 2 closes the statement in figure 1, and appends the extra select statement. The two dashes at the end of figure 1 are to comment out (in SQL Server) the apostrophe in figure 1's last dash. So your original SQL statement (figure 1) will now be executed as the following:

Select * from customer


where customerid = 'ALFKI';

select * from customers--'

 

Replacing single apostrophes with double apostrophes can be beneficial in this case. Of course the person doing the injections won't know the table names, but however will get the page to crash.

 

INTERFACE DESIGN:

The cost model uses (a)-(c) to compute and associate the following information in a bottom-up fashion for operators in a plan: (1) The size of the data stream represented by the output of Furthermore, in the System R optimizer, two plans are compared only if they represent the same expression as well as have the same interesting order. Despite the elegance of the System-R approach, the framework cannot be easily extended to incorporate other logical transformations (beyond join ordering) that expand the search space. It also determines the estimated size of the data stream for output of every operator in the plan

 

CONCLUSION:

Most web applications employ a middleware technology (scripting engine) designed to request information from a relational database in SQL parlance. SQL injection is a common techniques hackers employ to attack underlying databases. These attacks reshape the SQL queries, thus altering the behavior of the program for the benefit of the hacker. In this paper, we present a fully automated technique for detecting, preventing and reporting SQLIA incidents in stored procedures. The technique abstracts the intended

 

FUTURE ENHANCEMENT:

We believe that the SQLDOM4J solution, which was developed in the scope of a master thesis research project, could significantly benefit from improvements to its accuracy and performance; here are the main ones that we have identified. Column lengths (e.g. for varchar fields) could be stored in the DB class (as names and data types are) allowing the solution to perform bounds validation for input data and therefore increase its protection level and overall accuracy.

 

The main source of overhead is the use of the underlying DBMS-driven Prepared Statement interface and we believe that its use within our API could be limited while still offering a similar level of protection. For instance, accuracy tests have shown that type violations are successfully detected by the API. Hence, SQL queries which do not use variable text values could be built without the use of Prepared Statements, whose added value mainly pertains to text field protection.

 

REFERENCES:

1      Andrews, M.: Guest Editor's Introduction: The State of Web Security. IEEE Security and Privacy, 4, 4, 14--15 (2006)

2      Janot, E.: SQLDOM4J: Preventing SQL Injections in Object-Oriented Applications. Master thesis, Concordia University College of Alberta (2008), http://waziboo.com/thesis

3      McClure, R., Krüger, I.: SQL DOM: Compile Time Checking of Dynamic SQL Statements. In: 27th IEEE International Conference on Software Engineering, pp. 88--96. IEEE Press, New York (2005)

4      Power, R.: 2002 CSI/FBI Computer Crime and Security Survey. Computer Security Issues & Trends, 8, 1, 1--22 (2002)

5      Boyd, S., Keromytis, A.: SQLrand: Preventing SQL Injection Attacks. In: Nagel, W.E., Walter, W.V., Lehner, W. (eds.) ACNS 2004. LNCS, vol. 3089, pp. 292--304. Springer, Heidelberg (2004)

6.     http://www.owasp.org/images/7/74/Advanced_SQL_Injection.ppt

7.     http://oracle.com/technology/products/ias/toplink/doc/ 11110/devguide/ qrybas.htm#  CIHEBF

8.     http://www.owasp.org/images/7/74/Advanced_SQL_Injection.ppt

 

 

Received on 22.08.2014                                   Accepted on 20.09.2014       

©A&V Publications all right reserved

Research J. Engineering and Tech. 5(3): July-Sept. 2014 page 135-143